【レポート】スペシャルセッション:「企業の DevOps への挑戦 〜カルチャーの維持と育成～」(SP-05) #AWSSummit

この記事は、5月26日に行われた AWS Summit Online Japan 2022 のオンラインスペシャルセッション『企業の DevOps への挑戦 〜カルチャーの維持と育成～(SP-05) 』のセッションレポートとなります。 セッションのアーカイブも公開されていますので、詳細はそちらをチェックしてください。

ご興味を持たれた方は、ぜひ AWS Summit Online のサイトに公開されている資料もご確認ください。（登録が必要です。）

• 企業の DevOps への挑戦 〜カルチャーの維持と育成～(SP-05)

セッション概要

クラウド有効活用を前提とし、IT の流動性に合わせた開発モデルの整備が必要となっています。民法改正で請負契約における瑕疵担保の定義が変わり、SI 企業からも新しい形を求める声が増えています。リモートワーク、ワーケーション、副業など仮想化という概念がもたらす流動性は IT を飛び越えた領域にも影響を及ぼしています。内製化を目指す一方で、IT の流動性を維持するならば、それを支える人材の流動性も考えておく必要があります。このセッションでは日本版開発モデルの新しい案をお届けします。

スピーカー
AWS シニアエバンジェリスト　亀田 治伸

レポート

「企業のDevBizOpsへの挑戦」というタイトルに込められた想い

企業はクラウドを活用することで初期投資を最小化し、柔軟性の高い、変化に強いIT基盤を手に入れることが出来るようになりました。AWSではこの新しいスタンダードを「ニューノーマル」という言葉で表現している。

クラウドを活用したアプリケーション開発とセットで語られるのが「内製化の重要性」だと亀田氏は言います。

クラウドを活用した様々なチャレンジは残念ながら全てが成功する訳ではない。しかしながら、必ず学びがあります。それらをレポートとしてまとめ社内に承継していく必要がある。

そこに蓄積されたノウハウが次の新しいチャレンジを成功させる最大の要因となっていくという構造になるため、そのノウハウを正しく蓄積するための専用チームが企業にとって必要である。これがクラウドを活用したアプリケーション開発における内製化の重要性とセットで語られる背景である、と述べた。

いつ100%内製化に踏み切るべきか？

残念ながらIT業界全体で今日においてベストプラクティスと言われるものは未だない。その中で戦略的にクラウド活用いただく企業はどのようにチームを作っていくべきかという議論を日々重ねている。その議論の土台となる情報、ヒントを届けたいという想いから「企業のDevBizOpsへの挑戦」というタイトルにしたとは語った。

クラウドがもたらす「チャレンジとカスタマーサクセス」

2006年3月、Amazon S3が正式サービスとしてリリースされAWSが誕生して以降、企業にとってのITは「初期投資と時間の掛かるもの」から、初期投資不要、定額の変動費、従量課金型、長期契約不要といったサービス型へと変貌しました。クラウドは一度作ったものをいつでも世の中の変化、ユーザーの行動様式の変化に応じて作り変えることができます。

多くの企業からクラウドに対する期待値として「コスト削減」があります。当然、システム運用におけるコストも含めて考えるとコスト削減効果も期待できますが、それ以上に大きな効果が「チャレンジとカスタマーサクセス」だという。

「初期投資を最小化することは、撤退コストを最小化できていること」を意味します。企業はアイデアをすぐ実行に移すための基盤としてクラウドを使い、その中で多くのチャレンジを繰り返し、学びを蓄積し、最終的にそのチャレンジが成功へと繋がっていくという。

ビルダーの育成がイノベーションのカギ

発明への高い意志を持ち、課題をかかえる顧客体験に注目し、それらに正直に取り組み、再発明する方法を見つけようとする人々

Amazonでは「ビルダー」をこのように定義しています。クラウドを活用することで従来の作業はAPI経由で数分間で完結するようになりエンジニアの時間あたりの生産性は爆発的に向上している。多くのビジネスが最新のテクノロジーの恩恵を受けるようになり、エンジニアの重要性が益々と増している。

自発的にPDCAサイクルを回しながらビジネスに貢献していくことができるエンジニア、つまり「ビルダー」が自分たちの思いを具現化する環境を作ってあげれるか、モチベーションをどのように維持していくのか「これが経営者側の責務でありイノベーションのカギである」と説明した。

クラウド・イノベーション・ジャーニーのプロセス

AWSは現在200を超えるサービスを提供し、昨年には3,000回を超える機能拡張を提供している。つまり使っている間に進化していくIT基盤というものが実現されている。システムのクラウド移設は一過性のプロセスではなく、移設後もどんどん進化していくものであるという意味を込め、AWSではシステムのライフサイクルを「クラウド・イノベーション・ジャーニー」と呼んでおり、一般的に以下のようなプロセスを辿るという。

まず最初に「システムの統廃合」、その中で非常に重要なポイントはクラウドを活用するということは「持つ必要がないものを持たない」、より軽いITを実現すること。

「この発想はインフラだけでなくアプリケーションにも適用されるべき」と述べた亀田氏は、クラウド検討の初期においてまず検討いただくべきは「クラウドを使うべきかどうかではなく、どのアプリケーションを残すかどうか」と語った。

バックオフィス系、人事系など、いまは非常に安定したSaaSが世の中にたくさんあるので、そういったものをどのように取り込むかをまず検討し「残す」と判断したシステムをクラウドに持ち上げる。

クラウド上で稼働したシステムはコピーも容易になる。そのコピーは必要がなくなれば削除することで課金もそこで止まる。つまりオンプレミス状態でシステム改善を試みるよりも、クラウドに持ち上げてしまったほうがその作業はやり易く、コスト効率も良くなる。

そして必要に応じて様々なテクノロジーを付け加え、アプリケーションをモダナイズしていく、といったプロセスを経る。

今後10年間で「変わらないもの」を考える

Amazonファウンダーのジェフ・ベゾスがとあるイベントでこういった話をしています。

今後10年間に何が変わるかと思うか、頻繁に尋ねられる。
しかし、今後10年間に何が変わらないかを考えた方が、より重要な知見を得られる可能性が高い。

「お客様はより早く安く、より多くのものを欲している」

それらの実現方法がテクノロジーで進化するだけである。
不変の要望であれば、長期にわたる投資が可能となる。

「昨今デジタルトランスフォーメーションの重要性なども語られていますが、あくまでテクノロジーを使うことが目的ではない。一番最初にお客様が欲しいものを長期に渡って特定する作業を行い、そこに対してモノを提供していきましょう、この考え方はAWSだけではなくAmazon全てのサービスに共通している」（亀田氏）

SaaSの多くはクラウドで稼働し、少ない投資で高いセキュリティを実現している

「クラウドのセキュリティは多くのお客様から高く評価されています。クラウドのほうが高いセキュリティを実現できるという話ではなく、クラウドのほうが同じセキュリティを実現するのに、より早く、より安く到達できる、という点が重要」と述べる亀田氏は、その効果を中心として多くのSaaSはクラウド上で動いていると説明した。

基調講演で登壇されたデジタル庁をはじめ、多くの金融機関が既にAWSを利用している。つまり日本トップレベルのシステムが動作する同じセキュリティ基盤の上に、多くのSaaSが動いているという現状がある。

かつてビジネスのアーリーシードにおいて高いセキュリティレベルをいきなり作り出すことは難しかった。暗号化を一つの例にすると、暗号化そものもはコマンドひとつふたつくらいで終了する作業ですが、その一方で鍵管理を真剣に考えると堅牢な暗号化システムというのはコストも時間もかなり掛かるものです。しかしクラウドにおいてはその限りではありません。

多くのアーリーシードのビジネスやSaaSアプリケーションはクラウドを活用し高いセキュリティを適用できるようになったことで「エンタープライズ企業においてもSaaSは安定した選択肢になってきている」と述べた。

「そして自分たちが面倒をみるべきアプリケーションの数を減らしていくことで、エンジニアのリソース活用効率を上げ、よりイノベーションの方向、価値の高い方向に皆さんの時間を使っていただくことが出来るようになっています」（亀田氏）

MVP（Minimum Viable Product）お客様の声を可能な限り早く

「（アプリケーション開発の）初期フェーズにおいてまず皆様に志していただくべきもの」MVP（Minimum Viable Product)について亀田氏は、最初に時間をかけて大きなアプリケーションを作りすぎないことが重要だと説明した。

「社内の限られた関係者と会議を繰り返したところで、そのビジネスが世の中のお客様に必要とされているかどうかはわからない、というのがその背景です。」（亀田氏）

特に今はSNS、スマートフォンなどによりユーザーの思考は細分化していると言われている。マーケティングリサーチをし、新規のビジネスを作ったとしてもそれが世の中に受け入れられない可能性は十分にある。

であるならば、なるべく早く必要な機能だけを具現化したアプリケーションを作り、それを世の中に出し使ってもらいながらフィードバックをもらうことに注力する。「フィードバックを精査しアプリケーションを育てていく、このようなビジネス開発が今必要とされている」と述べた。

「MVP という考え方、お客様中心にビジネスを育てているという考え方はクラウド、ソフトウェアのアプリケーション開発だけではなく非常に多くの業界に影響を及ぼしています。なぜならIT、クラウドに関係なくユーザーの志向というのが細分化し続けているからです」（亀田氏）

グローバルでの製造業トレンド

ひとつの例として紹介されたのは製造業におけるグローバルのトレンド。昔のサービス部門というのは余程クリティカルな問題でなければお客様から来たクレームを社内にフィードバックしない。「設計部門には設計に集中させる、ちょっとしたクレームはサービス部門だけで完結する。それが美しい姿とされていた」と説明した。

しかし今はSNSがある。ユーザーは自分の問題が解消されなければ情報発信できる手段を持っている。したがってユーザーの意見をどのようにサービス開発に反映させるかという考え方が重要になっています。

「それともうひとつ大事なのは実際にそのサービスを改善できる可能性のある意見を持っているのは、そのサービスを普段使っている人たち」と述べた亀田氏は、サービスを売っている人たちには見えないものがある、したがってサービス部門をきっかけにビジネスの改善サイクルを回していく、こういった形でITの関係ない業界においても様々な取り組みが行われていることを紹介した。

アジリティとガバナンスを共存させる「ガードレール」

このような背景からエンジニアには自由な開発環境を与え、自由にアプリケーション開発できるようにしていきたいと考える。ただしセキュリティは企業にとっての生命線であり、ひとつの情報漏洩がビジネスだけでなく企業イメージ全体を毀損することもある。

特にクラウドの場合、ITリソースは柔軟に変動する。サーバーが増える減る、新しいテクノロジーのサービスが起動する、そうやって変動するITリソースをどのように管理していくべきか？

• オンプレミスのシステム
  • サーバーが納品されると環境セットアップが開始される
  • セットアップが終わるとアプリケーション開発が行われる
  • 商用リリースする前にコントロールの有効化が行われる
    • アプリケーションレイヤーであればペネトレーションテスト
    • ハードウェアやOSレイヤーであればハードニングを施すべきライブラリをインストール
  • アプリケーションが出来上がった後、色々な作業が行われる
    • ときにはアプリケーションに影響を与え、開発をやり直すということも発生

このような状況がなぜ起きるかと言えば、オンプレミスのシステムは現場がそのシステム、OSに対するフルコントロール権限を持っているからだと説明した。

一方AWSの場合「全てのITのリソースがAWSの単一管理基盤、単一の認証認可基盤を介して操作されるというのが大きな特徴です。これはうまく使えばシャドーITのようなものを防ぐことが出来る」といいます。

• AWSのシステム
  • まずAWSのアカウントを起動直後、全体としてコントロールを有効化する
  • 有効化された範囲のなかで自由に作業できる権限を開発チームに払い出す
    • 従来のセキュリティの在り方を逆に出来る
  • あらかじめ設定された予算、統一セキュリティ基準を設定しておく
    • 本来企業で許可していないSSHのポートをインターネット側に開けた
    • 開発環境の予算に近づいているといった状況
      • 管理者にアラートとして送ることができる

AWSではこの考え方を「ガードレール」と呼ぶ。

従来のセキュリティは「赤信号型」

アプリケーションレイヤーなど最終的なリリース前のペネトレーションテストにおいては引き続き赤信号型が必要な領域もあるが、従来はすべてが赤信号型だったものを一部ガードレール型にすることによって全体のアジリティをあげていくという考え方です。

開発環境においても適用する

AWSには多くのセキュリティサービスがあります。オンプレミスの場合、一般的にセキュリティ系のサービス、ツールは非常に高価であるため、本来はそれが望ましいとされながらも開発環境に全てを適用することは難しい。

AWSであればすべてが初期費用不要の従量課金です。必要な機能をまず最初にすべて有効化し、そのうえで必要ないものを無効化していく。「必要最低限の、そして必要十分なセキュリティを実装していくことが柔軟にできるようになっている」と説明した。

エンタープライズの現状

「このようなAWSのセキュリティへの考え方は多くのお客様に評価され、多くの企業がイノベーション、ビジネストランスフォーメーションを目指す中でクラウドファーストを掲げていただいています」（亀田氏）

ガートナーのレポートによれば「88%の企業がクラウドファーストを掲げている」、その一方でまだ「86%のIT予算がオンプレミスに使われている」という現状。

既存システムをクラウド化していくというのは大変なプロセスであるということが、この数字からうかがい知ることができますが「これは時間とともに減っていくとAWSでは考えています。なぜならシステムをクラウドに移設し必要な運用改善、セキュリティ改善がなされたシステムにおいては明確に様々な数字が改善することがわかっています」と述べた。

企業におけるクラウドの価値

IDCのレポートによれば「平均的なインフラコストは31%削減」となり「1年間で削減可能であったセキュリティインシデントは43%改善」したといいます。（実際のインシデント以外にヒヤリハットも含めた数字とのこと）

またデータセンター、ハードウェアなどの障害対応における工数が最小化されたことにより「ITスタッフの生産性は62%向上」し、結果として「1年間に従来より3倍の新機能をリリース」出来たという数字が報告されています。

こうしたコスト削減効果以外の隠れた価値が存在しているということが外部による調査で判明している。

DevBizOps

多くの企業がクラウドを活用しアプリケーション開発を志していますが「それとセットで重要視されているキーワードがDevOps」だと紹介した。

「Dev」はアプリケーション開発チーム、「Ops」はシステム運用チームを表す言葉ですが「明日からDevOpsをやろう！とシステムの運用部隊とアプリケーション開発チームを同じ部署にする。これは多くの場合うまく行かない」と述べた。

「その原因は経営層から別々の指示が出ているから」と説明した亀田氏は、インフラ部隊、運用部隊は既存の収益を支える基盤を安定させることが第一の責任であり、そこから更に追加で捻出したリソースで新しいことにチャレンジする、これがOpsチームのやるべきこと、一方、既存ビジネスの改修も含め新しいことを次々にやっていくのがDevチーム、と述べた。

必然的に二つのチームの思いが異なるためコミュニケーションはすれ違う。この問題を解決するために「一緒のチームにしてしまおう」という発想になりがちだが「異なる指示が出ている」という問題を解決しない限り、近くなった分、問題はより大きくなる現象が発生すると紹介した。

「Amazonの場合これは経営者の問題」と説明した亀田氏は、「二つのチームに何かしらの問題が起きるのは経営者から別々のことを言われているからだ、それがAmazonの考え方です」と述べた。

この問題を解決するには二つのチームがやるべき責任を一つに統一する必要があり、それはビジネス指標。

「世の中的には実はDevOps、最近では『BizDevOps』という言われ方をするんですけれども、私は敢えていつもDevとOpsをつなぐのはビジネスですよという意味で『DevBizOps』という話をしています」（亀田氏）

Conwayの法則

ここから少しアプリケーションアーキテクチャ、マイクロサービスアーキテクチャとセットで語れる「Conwayの法則」を軸とした話題へと移っていきます。

いかなる組織のシステム設計においても、生成される設計は、組織のコミュニケーション構造のコピーとなる

1967年、技術者だったメルヴィン・コンウェイが残した言葉ですが、「都度、マネージャーの承認がデプロイに必要な組織はウォーターフォール型に必然的にアプリケーション開発スタイルがなっていく、結果として生み出されるアプリケーションもそうなっていく」と紹介した。

マイクロサービス

従来のひとつの巨大なアプリケーションを複数のチームが意識をあわせながら作るのではなく、目的単位でアプリケーションを小さく分割し、必要に応じてAPI経由で有機的に連結、結合する。「これがマイクロサービスアーキテクチャの基本的が考え方」と紹介した。

先ほどのConwayの法則に従えば、「マイクロサービスアーキテクチャをとるのであれば、それぞれのアプリケーションを支えるそれぞれのチームが必要になってくる」と前置きしたうえで亀田氏は続けて述べた。

「実際ここはひとつの勘違いを生みやすい、我々も説明が悪いケースがあるんですが、クラウドでクラウドネイティブアプリケーション開発、サーバレス、コンテナ、機械学習などを活用したモダンなアプリケーション開発をする際にマイクロサービスアーキテクチャが望ましいのかといえば、実はそうではなかったりします」（亀田氏）

初期フェーズにおいてはモノリシックの方が作用する

マイクロサービスアーキテクチャの対極にあるのがモノリシックアーキテクチャ。

ビジネスの初期フェーズ、各チームがスピード感をもって自由にアプリケーション開発を行うよりも重要なこと。それは「リーダーの想いをその場にいる人間が全員正しく理解できているか？」

アプリケーションの開発能力を向上させることも重要だが、初期フェーズにおいてはモノリシックアーキテクチャの方が比較的うまく作用しやすいと言われている。なぜなら「全員がリーダーの想いを理解する時間を取れるから」と述べた。

アプリケーション分割のタイミング

順調にビジネスが立ち上がりある程度時間が経過するとアプリケーションは複雑化する。特に今はユーザーの要望は多用化し続けているため、様々な機能が追加され続け、放っておくと中身はより複雑になる。

「シニアのマネージャもしくは経営者から見てコミュニケーションの問題が増えてきたな、というタイミングがアプリケーション分割のタイミング」（亀田氏）

独立したデプロイ性を維持すること

まずはモノリスを作り、必要に応じて分解していく。そういったプロセスが望ましいと言われていますが、その際にもうひとつ重要な点がある。

「個別のアプリケーションは必ず個別の独立したデプロイ性を維持する必要がある」

「これは技術的な話だけを言っているのではなくビジネス判断もそこに包含されている」と説明した亀田氏は、そのチームがアプリケーションに責任を持ち、お客様の声、収益に責任を持ち、自分たちの判断で必要と思って機能をデプロイしていくことが非常に重要だと述べた。

ビジネス判断が分解できない中でマイクロサービスアーキテクチャを志した場合「分散モノリス」になるといい、「ものの本によると分散モノリスは最悪のアプリケーションアーキテクチャだという風に定義されています」と紹介した。

AmazonのDevBizOps

Amazonの基本的な考え方として「アプリケーション開発が完了してからが、あなた達のチームの正式な仕事が始まる」それはメインのお客様が使いはじめるからだと亀田氏は紹介した。

お客様から得られた要望をいかに素早く反映する、もしくは自分たちがこうありたいと思っていたものが「違ったな」と思ったときに、いかに素早く修正していけるのかということを中心に考えた場合「開発チームはそのまま運用に回ってください。いろいろ試しましたがそれが一番効率がいい」と述べた。

お客様にとって一番満足度の高いアプリケーション開発体制を作る。もし、それをやる中で出来ない要因があるとすれば「それは経営者が責任を持って解決する」

これがAmazonのDevOps、そしてDevBizOpsの考え方であると述べた亀田氏は「そしてこの考え方の延長戦としてAWSクラウドコンピューティングが生まれた」と説明した。

モノリスからマイクロサービスに移行するタイミング

もともとAmazon.comのECサイトはモノリシック型で開発されていた。「お客様の声を重視するAmazonの開発スタイルは様々な細かい機能を既存のメインのブランチに統合していきます。」と説明した。

そうするとアプリケーションは密結合状態になり、あまりに複雑化しすぎたとき一人の人間がすべてを理解できる物理的限界を超える。メンテナスや新しい機能投入のビルドやテストが複雑化していく。

この状態を長く維持しておくと組織的に現場で責任をとれる人が生まれていく。

「それ自体は素晴らしい。その人がもつノウハウ、高い生産性などをもとに色々なものを判断し、やっていいよ、それ危ないかもしれない、と判断してくるわけで」と前置きしたうえで亀田氏は続けます。

「経営サイドからすると、ある一定期間経過すれば想像以上の権限や判断がその人に集約しています。さらに長い期間が経過すると特異点となり新しくその組織に入ってきた人間がお伺いを立てないと新しいことができない、という状態が発生します。」（亀田氏）

つまり属人性が最大化してしまう。

このような現象が見られたときにモノリスからマイクロサービスに移行するひとつのポイントになる、と説明した。

DevOpsからDevBizOpsへ

独立したひとつのチームは「アプリケーション開発」「システム運用」この二つの機能において「お客様満足度」に対する責任を持ってもらう。

Amazonがなぜこのような考え方に行き着いたか。亀田氏は「モノリシックアーキテクチャ開発をしている時代のAmazon.comはものすごく悩んでいた時期がありました」と紹介した。

インフラ部隊とアプリケーション開発部隊の仲が悪くなっていたという。意思の疎通がとれない、意思の疎通をとろうとしても打ち合わせの時間だけが伸びていく、時には諍（いさか）いが止まらない。

この問題を当時CEOだったジェフ・ベゾスは、様々なコンピュータサイエンスの専門家を呼んで議論したといいます。その結果生まれたひとつの答えは非常にシンプルでした。

「打ち合わせをさせないためには作業の順番を入れ替える。」

インフラ部隊には汎用性の高いインフラをAPI付きで作り続けてもらう、汎用性が高くAPIがあれば要件定義の打ち合わせは必要なくなるのではないか？その結果としてAWSが誕生したと説明しました。

なんでもミニマムに作れば良いという話ではない

MVP(Minimum Viable Product)についてもう少し紹介します。

まず小さいものを作ってリリースしましょう、という考え方がうまく関係者間で意思の疎通がとれないケースがある「大事なのは目的、つまりユーザーに提供できる価値」と説明した。

例えば「車」という乗り物を開発しようとするとき、最初に小さなものを作ろうといって「タイヤ」だけを出されてもお客様は困ります。

（引用元：Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable）

そうではなく、最終的な目的が「移動手段」なのであれば、まず移動できるという方式を提案する。例えば「スケートボード」からはじめ「キックボード」「自転車」「バイク」へと発展させていく。

こういった視点でMVPを作っていきましょう、と説明した。

Two-pizza teams

「マイクロサービスアーキテクチャを採用したとしても、チームのビジネスが順調に成長すれば機能と人は増える」と亀田氏は述べた。

どうするかといえば「チームの上限」を決めます、いわゆる「Two-pizza teams」と言われるものです。およそ7名〜10名程度をチームの上限とする。

機能が増えチームが複雑化、人が増え続けるのであればアプリケーションを分割してAPIを作る。そのチームはDevBizOpsに基づき作るものすべてに責任を負う。

ロードマップ、実際の開発、運用、サポートのエスカレーション対応、収益、ユーザー数など、すべてをチームの中で完結し、ビジネス判断を委譲し、アプリケーションを成長させるようにしていく「これがTwo-pizzaチームの基本的な考え方」と紹介した。

日本のアプリケーション開発

ここから日本版のアプリケーション開発、SIerとの付き合い方へと話が移っていきます。

日本はSIer、外部の開発リソースの依存度が高いといわれますが「米国にもSIerは存在する」と紹介した亀田氏は、大きく違うのは「コントロールセンター、設計を書く人間であったり、プロジェクトマネジメントする人間であったり、そういう人たちが社内にいるのが米国式のスタンダードになっている」と述べた。

先程、「アプリケーション開発をしたチームはそのまま運用に回ってもらうのが一番いい姿だ」ということを紹介しました。アプリケーション開発が終わっても社内で開発者が滞留するということはなくなりますが、都度、新しいことをやるために新しい開発者を確保しなければいけない。

日本の場合、「米国と違い人材の流動性が起きづらい社会構造になっています。これは国民性の問題だけはなく様々な規制によるもの」だという。「したがって外部リソースとどのように柔軟に付き合ってイノベーションを起こしていくのかというのは、やはり考える必要がある」と述べた。

IT開発のモデル変遷

クラウドは使っていく間にITが進化していく、コストも削減していくという状況を作り出しています。当然ながらお客様側からすると「クラウドと同じペースでアプリケーションを進化させるための手法を模索したい」「請負型からタイム＆マテリアルのサービス型で、どのように外部リソースにアプリケーション開発を依頼していくのか」という考え方が生まれる。

一方、アプリケーション開発側です。2020年に民法が改正され従来「瑕疵担保責任」と言われていたものが「契約不適合責任」に変わった。

瑕疵担保責任は納品から一年間が最大期間だったが、契約不適合責任の時効は五年に設定されいています。(ここでは主観的起算点の時効である五年について述べられていると思いますが、客観的起算点を用いた場合の時効は十年になります）

（債権等の消滅時効）
第166条　債権は、次に掲げる場合には、時効によって消滅する。
一　債権者が権利を行使することができることを知った時から5年間行使しないとき。
二　権利を行使することができる時から10年間行使しないとき。

個別契約で短く設定することも可能とは考えられるが、お客様から「なぜ一年なの？」という圧力は当然強くなる。

このようなことを考えるとアプリケーション開発事業者側からもやり方を変えていきたい。その方が柔軟性の高い状態を作り出せてお客様にもメリットがあるはず。

よって「『DevOps型』『アジャイル開発型』が多くの企業によって検討開始されいるが、その中で重要だと言われる考え方が『バイモーダル』」と述べた。

バイモーダル

「バイモーダル」はガートナーが提唱した考え方です。社内には以下、ふたつのチームを同居させます。

• モード1
  • 従来のウォーターフォール型のアプリケーション開発を行うチーム
• モード2
  • 新しい事業、新しいアプリケーション開発にチャレンジするチーム

一般的にモード1は既存事業を支えるシステムに適用される考え方、もしくは基幹システムに適用される考え方です。拙速に新しい技術を採用しお客様の声を反映させるよりも、複数いるビジネスステークホルダーの合意をもとに改善していくという考え方が重要になる。このため、クラウドを活用しアプリケーション開発するとしても、必ずしもアジャイル、マイクロサービスは必要ない。

「既存事業を支えるために生み出された様々なITにまつわる社内の運用ルールは正しいわけです、なぜならビジネスはそこで成立しているわけですから」（亀田氏）

一方、モード2というのはアジャイル型が採用される。とにかく改善したいと思ってからリリースまでの時間を短くしておく必要がある。昔よりはるかにユーザーが強いため。

「多くのビジネスが従量課金型、サブスクリプション型になっていく中でユーザーは複数のビジネスを簡単に移動できるようになっている」と述べた亀田氏は、ユーザーから寄せられたクレームに対して真剣に取り組み、素早くそれを反映させていくことが重要になるといいます。安定性やセキュリティも重要だが、それよりもユーザーの声をいかに素早く反映していくかということを中心に考えていく、というのがモード2の考え方だと紹介した。

抽象化

従来のモード1はエンジニアを技術スタックことにチーミングする、という考え方が主流でしたが、クラウドによる様々な技術の抽象化によって変化が訪れているといいます。

例えばサーバーレスコンピューティング。Java、Python、Nodeなどソースコードをアップロードしておけばイベントドリブンでプログラムが実行される。その実行を支えるためのライブラリなどはAWSが管理する。

「様々なものが抽象化されて行くのであれば、従来の技術スタックごとにエンジニアをチームとしてまとめていたものが引き続き有効なのかどうか、新しいビジネス開発においてそのスタイルは引き続き有効なのかどうかを一度考え直していただき、新しいスタイルの方が良さそうだと言うことであれば切り替えていく」そんな考え方も必要だと亀田氏は述べた。

モード2型がお客様を満足いただくためのチームなのであれば、ひとつのチームに全機能がそろっていたほうが当然お客様の満足度は高くなる。そういった形にしていくかどうかをもう一度考える、それがバイモーダルの考え方だと説明した。

Conwayの第二法則（逆法則）

先程ご紹介したConwayの法則はよく語られていますが、一方、第二法則、逆法則というものがある。

「逆も真なり」

つまりアジャイル開発的なモード2の物が必要なのであれば最初からそのチームを作ってしまう、それがConwayの第二法則といわれるものです。

「権限委譲が新しいチームをうまく回すのに非常に重要」と述べた亀田氏は、権限委譲というものはそのチームに配属される開発者、エンジニアからすると必ずしもすべてがプラスに働くわけではないという。

ナラティブによるレポーティング

何が重要になるかといえば「レポーティング」だと説明した。

権限委譲する新しいチームを作る、そのチームの収益の責任を持ってもらう、お客様の声を重視しながら自由に開発をしてくださいというスタイルをとるのであれば「従来マネージャーが行っていたレポーティング業務はそのチームがもちろんやるべき」と亀田氏は述べた。

「Amazonでは重要な会議においてPowerPointは禁止されている」と紹介した亀田氏は、その理由についてPowerPointは多少論理構成が破綻していたとしても押し切ることができるからだと説明した。一方、Wordの場合は論理構成の破綻が浮き彫りになりやすい。

「そしてこの同じレポートフォーマットを使って既存事業だろうが、新規事業だろうが、エンジニアリング部隊だろうが、人事であろうがマーケティングであろうが法務であろうが全てレポートする」（亀田氏）

「これは異なる文化を持つ二つのチームを融合するひとつの手法として役立てられている」と述べた亀田氏は、これをAmazonでは「ナラティブ」（叙述形式・叙事文）と呼んでいると紹介した。

反復性の向上からConwayの法則　最終形態へ

立ち上がってきた新規事業、新規アプリケーションはお客様の声をいかに素早く反映させていくかを考えていくためには「反復性をあらかじめ視野に入れた設計をする必要がある。」と述べた。

• インフラレイヤーにおける反復性の向上
  • Infrastructure as Code、ソースコードでインフラを定義する
  • 人手で作業したものは再現性の担保が困難になり、人による作業ミスも発生する
• アプリケーションレイヤーにおける反復性の向上
  • CI/CD、連続的なインテグレーションおよびデプロイという考え方が重要

AWSは様々なツールを提供している。もちろん好きな外部のサービスを使ってもよい、と前置きしたうえで「重要なのはなるべくサーバーレスであることを検討してください。サーバーを持つと今度はそこの管理、障害時の対応、リソース不足などに悩まされます。可能であればサーバーレス型を提供してほしい」と説明した。

そして日々反復的にこの作業が行われるようにチームがなった場合「Conwayの法則　最終形態」へと入っていく。

反復的に行われる作業は組織そのものであり、引き継げない

チームリーダーの考え方、開発者をリードしている開発者の考え方が反復的に作業基盤に反映される。それはチームのカルチャーそのものであるから「引き継げない」という。

オーナーシップ

「外部の開発リソースにアプリケーション開発をお願いしたとしても、CICDであったり連続的なインフラのデプロイの作業は引き継げないです。我々はこれを『オーナーシップ』という言い方をしています」（亀田氏）

最初は外部に作ってもらったとしても「必ず自社がオーナーシップを持って、自社でメンテナンスできるようにしておかなければ、連続的なアプリケーション改修は実現しない」という。

もし、そのような状況になければ「マイクロサービスアーキテクチャ、Two-pizzaチーム、バイモーダルと言ったところで結果が出せないという現象が発生する」と説明した。

社内にテクノロジーのブラックボックスを作らない状態にする。外部に委託したのであれば、必ず受け取って理解できるようにしておく。または、責任範囲を明確化し問題が起きた時に誰が動くべきかを瞬時に判断できるようにしておく。

責任分界点としてのコンテナ利用

そのなかで期待されているテクノロジーが「コンテナ」です。

コンテナはモダンアプリケーション開発において人気のあるテクノロジーですが「権限、責任範囲の分界」という意味においても非常に有効に機能する、と亀田氏は述べた

• 仮想マシンの場合
  • ゲストOSは仮想化されているとはいえブートシーケンスを通り、そこで必要なライブラリの読み込みも行われる
  • 仮想マシン上で複数のアプリケーションを動かし、それぞれ異なるライブラリのバージョンを使いたい場合がある
  • そういったアプリケーションが外部リソースから納品された場合、その作業はかなりややこしい
  • ややこしくなるので「OSやライブラリ管理も、そっちで面倒みてよ」という話になりがち
  • 徐々に責任範囲はぐちゃぐちゃになる
• コンテナの場合
  • OSが起動済みの中で依存関係を持つライブラリを読み込みプロセスだけが起動する
  • それぞれのアプリケーション実行環境はコンテナに閉じ込めることが出来る
  • 責任範囲を明確にすることが出来る

すでに一部の先進的な国内企業では、外部にアプリケーション開発を委託する際「納品形態はコンテナとする」という宣言をしている、と紹介した。

モノリスからマイクロサービスへ

通常マイクロサービス化はAPIベースで連携するが、データドリブンでシステムを非同期に連携するという考え方を取り入れることも出来る、と亀田氏は述べた。

例えばSAPはパッケージされたソフトウェアなのでユーザーが自由に手を入れてマイクロサービス化できるものではない。一方、「SAPが吐き出すデータ」を非同期で分析サービス、BIツール、機械学習基盤などに組み込んでビジネスを発展させる可能性はある。

分散モノリス

このような考え方をとった場合「分散モノリス」というアプリケーション形態になる。

先ほど「分散モノリスは最悪なアプリケーション形態と言われている」と紹介しましたが、これは「意図せずそうなった場合は最悪だ」ということであり、最初から「各機能で独立したデプロイ性を確保したい」「ビジネス判断は分割できないけどね」という前提で分散モノリスになることは必ずしも悪いものではない、とも言われている。

重要なのは「イベントドリブン型であること」だと亀田氏は説明した。

DB分割の考え方

この考え方はEC業界において「ヘッドレスコマース」と言われている。

EC業界では純粋なマイクロサービスではなくヘッドレスコマースになっているかといえば、ECサイトは個人情報の塊。クレジットカード番号も含まれる情報を分割したいか？と問われた際に、やはりデータベースはひとつにしておきたい。

ただし、ユーザーがアクセスしてくるフロントエンドはマイクロサービスの良いところを取り入れ、柔軟性を持っておきたい。結果としてヘッドレスコマースという考え方生まれた。

例えば既存のデータベースがあったとする。アプリケーションごとにデータベースの射影、マテリアライズド・ビューを作る。ぞれぞれの射影に対して、異なるセキュリティを設定することが出来る。

ひとつのデータベースを複数のアプリケーションへセキュリティ設定するよりは責任分界点が明確になる。作業範囲も極小化することが出来るのでミスが起きづらい。

メインのクレジットカード番号などを持つシステムに対して、本当に発送システムがアクセスする必要があるか？ということを考えた結果、住所と名前だけをイベント型で発送システムにコピーすれば良い、そうすると万が一発送システムに何らかセキュリティ設定ミスがあっても、物理的にクレジットカード番号がそこには存在しない、という状態ができる。

「こういったことを繰り返しアプリケーションの機動力をあげていくことでABテストなどもやりやすくなる、ユーザーの使い勝手を中心としたシステムの考え方になっていく」と説明した。

運用性とは

ここから少し運用の話に入ります。クラウドは必要なときにITリソースをいつでも増やす、減らすができる。それらを自動化することもできるのでシステム監視の在り方も変わってきます。

AWSでは「ビジネス価値を提供するためのシステムの実行とモニタリングおよび継続的なプロセスの手順と改善」と定義されている。

「実はシステムの障害が起きているかどうかという考え方はDevBizOpsの中で変わる」と説明した。

• 従来のOpsの観点
  • インスタンスがダウンしていない
  • アプリケーションが500番エラーを吐いていない
• BizOpsの観点
  • インスタンスはダウンしていない、HTTPも200番を戻している、という状況とユーザーがいま嬉しい状態かどうかは異なる
  • 単にユーザーがアクセス出来ているかどうかではない
  • アクセスしてから0.5秒以内にサイトが表示できているか

「それを実現させるためにはアプリケーションのパフォーマンスチューニングも必要になりますからDevとOpsが同じメトリックスで会話をしていく、これがAWSが言うところのビジネス価値を提供するための運用性というものになります」（亀田氏）

メトリクスの合意

したがって新しいチームはアプリケーション開発にすぐ取り掛かることも重要ですが、初期フェーズは少し時間をかけてビジネス関係者と日々レポートすべき項目を考える、考えた結果としてアプリケーションでどのようなデータを取得するべきかが決まる、と亀田氏は説明した。

あらかじめ改善計画を作っておくことも重要。権限委譲されたチームを作るということは、そのチームの独立性を今度は守る必要がある。経営者が求めているレポートがリアルタイムで出てこない、頻繁に問題が長引く、こういった状態が定期的に発生している場合、独立性が剥奪されるケースも出てくるため、初期フェーズにおけるメトリクスの合意は非常に重要だといいます。

改善計画が出来たあとやるべきことは「レポーティング」です。

レポートフォーマットは経営サイドと合意する必要がある。そして合意されたレポートフォーマットは可能な限りにおいて他の既存事業の部隊からもいつでも見れるようにしておく「こういった義務を果たすことでバイモーダルはうまく回り始める」と述べた。

レポート精度を低下させないための抽選会議

そうすると次の課題が出てくる。マイクロサービスアーキテクチャを採用し、Two-pizzaチームが社内で増えるとレポートがたくさんの経営者のもとに集まる。すべてを見る時間は取れない。レポートを作る側からするとレポートを出してもほとんどコメントが来ない「この状態は非常に危険です。徐々にレポートの精度が下がっていき曖昧な状態になる」と述べた。

AWSではこの問題を解決するために「抽選会議」という仕組みを取り入れている紹介しました。

• とある会議には全チームが発表する想定でレポートを準備させる
• ある程度無作為に抽選を行い、発表してもらうチームが決まる

「こういったことやることによって本来、発表されないサービス、限られた経営者の時間の中でもみんな緊張感をもって資料を準備する」と説明した。

仮想化がもたらしたもの、もたらすもの

ここから仮想化というものが人のキャリアにどのような影響を及ぼしているか、といった話題が移っていきます。

「仮想化」というのはクラウドを実現させたEC2を生み出しただけではなく色々な領域に影響を及ぼしているひとつの例として「Uber」を紹介した。

• Uberは多くのモノが仮想化されている
  • ITインフラはAWS
  • 人の雇用
  • 車の確保
  • 配車システムはアプリケーション

既存の事業者は守るもの（既存ビジネス、既存資産）があった、その守るものをどうハンドリングすべきかを考えている間に、Uberは瞬く間に進展していき業界を塗り替えてしまった。これが「Uberlization」という経済用語になっている、と亀田氏は説明した。

よくクラウドは電気、ガス、水道のように捻れば出てくるITリソースと言われます。その一方で「サービス」は歴史的にすべて従量課金化しているという。スーパーマーケット、美容院、牛丼屋、コンビニ、ラーメン屋、、すべて従量課金型。

「サービス産業が従量課金化するというは非常に当たり前の考え方であり不可逆です」（亀田氏）

そしてITがサービス産業であると最初に宣言したのはIBMです。そこから数十年が経過した今、IT産業がサービスではないと言う人はほぼいない。「サービス産業なのであれば従量化していくのは必然です」と述べた。

いま、コロナの流れと相まって多くのオフィスは仮想化しつつある。日本で有名なトラディショナルな企業でさえフルタイムリモートワークを許可しているという。「当然そうなれば次にくるのはワーカーです。人も仮想化するパラレルキャリア」だという。

「そういったことを考えると完全なる100%の内製チーム、それは実現できれば美しいですが、ここまで色々なものが仮想化し、サービス化・従量課金化していく中でどのように人も流動性を担保しておくか、というのは必要な考え方ではないか」と述べた。

エンタープライズ・トランスフォーメーション

いま非常に世の中の変化は激しい。2011年末に存続していたS&P 500の企業のうち2027年に存続しているのは25%だろうと言われている。

ユーザーのライフスタイルの変化や行動の多様化、そしてビジネスの競争が激化しひとつのビジネスの存続期間が短くなっている。

「残念ながらこの流れというものは不可逆であり止めることはできない、とAWSでは考えています」（亀田氏）

• コアのビジネスは否定されるべきではなく非常に重要なもの
• どうやったらそれを進化させていくことができるかを考える
• 時にはユーザーのデータ分析をもとにイノベーションを起こしていく
• そのようなことを撤退コストを最小化したクラウドをフルに活用し、柔軟にITを使う

亀田氏は「そこで得られた様々なチャレンジの中で蓄積された学び、社内に正しく蓄積されることでいつの日か新しいチャレンジは成功に向かっていく。その中で非常に重要なのはお客様との対話です。これこそが日本のデジタルトランスフォーメーションを実現させるために必要な考え方である」として締めた。